IBIS Macromodel Task Group

Meeting date: 01 December 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI):                  Xingdong Dai
                              Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
Cisco:                        Seungyong (Brian) Baek
eASIC:                        David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
GlobalFoundries:              Steve Parker
Intel:                        Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:              John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.:                 James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys:                     Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong


The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Arpad reviewed upcoming ATM meeting dates and proposed that we cancel the
  meetings on December 22nd and 29th.  Therefore, we will meet December 8th,
  December 15th, and then not until January 5, 2016.  No one objected to this
  plan.  Walter noted that he will not be able to attend on December 15th.

--------------------------
Call for patent disclosure:

- None.

-------------
Review of ARs:

- None.

-------------------------
Review of Meeting Minutes:

- Arpad: Does anyone have any comments or corrections? [none]
- Walter: Motion to approve the minutes.
- Arpad: Second.
- Arpad: Anyone opposed?  [none]

-------------
New Discussion:
  
New Redriver Flow BIRD:
- Arpad: I would like to start with an update on the state of the offline
  discussions on this topic.
- Walter: Fangyi and I agree on two issues:
  - 1.  The existing flow is incorrect when Rx models have optimization loops
        in them, for example for a DFE.
  - 2.  The BIRD I sent to Fangyi states that for a statistical flow we have
        to change the order of what gets input to the Rx.
- Arpad: You mentioned "optimization," could you clarify if this only applies
         if the models have optimizations in the algorithms, or if the DFE block
         is there at all?
- Walter: It applies if there is optimization inside the model.
  - If the equalization applied in the Rx is a function of its input, then its
    input must include the info from the IR that went into the redriver Tx.
  - It's independent of the type of equalization, linear or not, etc.  If the Rx
    model is optimizing itself based on its input IR then the existing flow has
    this problem.
- Walter: We had an interesting discussion:
  - What do you do if you're doing a time domain flow (Tx has GetWave()) and the
    downstream Rx does not have an AMI GetWave()?
    - There may be things you can do to make it better.
    - We couldn't agree on anything that rigorously solves the issue.
    - We just have difficulty when an Rx doesn't have a GetWave() and you're
      forced to use GetWave() upstream and the Rx optimizes itself based on its
      input IR.
    - As a practical matter nearly all Rx models optimize themselves.
    - We could not agree to a change in flow or alternative inputs, etc.  All
      the solutions were problematic.  A DFE is non-linear and one gets into
      problems if it is not simply used as part of the main channel simple
      statistical flow.
  - I think Fangyi and I agree that if a model maker can write an Rx AMI_Init()
    function that does what they want, then there is no reason they can't just
    write a GetWave() function to apply that equalization to whatever is passed
    in to GetWave().
  - We think it's ill-advised for a model maker to create optimizing Rx models
    that are Init() only.
  - Fangyi thinks we should require that such models have a GetWave().
  - Perhaps "strongly suggest" that GetWave() be provided.
  - Maybe it's a quality or best-practices issue.
  - It would be a lot easier for us to have model makers put GetWave() into
    their Rx models, rather than having us try to define alternative IR inputs
    into the AMI_Init() function.
- Discussion: Fangyi agreed with Walter's summary.  Arpad commented that if we
  didn't require model makers to provide GetWave() functions with their Rx
  models, then we would still have to deal with the possibility of Init() only
  models.  Fangyi agreed and said that this was why he still felt that we needed
  to add the additional IR to be passed into the Init() function, so we could
  deal with the Tx GetWave(), Rx Init() only scenario.  Walter commented that
  using deconvolution to the get the equalization of the Rx and then applying
  that to the Tx GetWave() output convolved with the downstream channel was
  another alternative.  Walter suggested that Fangyi could draft the proposal
  specifying the additional IR to be passed in, defining a new Reserved
  Parameter to indicate that it was there, etc.  Fangyi said that he probably
  wouldn't get to this until the new year.  Mike L. asked if adding the
  additional IR would mean that we needed to revisit any of the mathematical
  process descriptions in the spec.  Fangyi said we would not, and Walter
  agreed.
  
Discussion of language corrections regarding "ground":
- Arpad: We need to start by deciding on a few things:
  - I think it might be easier to make these changes by editing the main 6.1
    document.  If we run into additional major or technical changes, then we
    could write additional BIRDs for those changes.
  - Should we start additional meetings in the normal Friday time slot for the
    editorial meetings, or should we simply work on it here in this meeting?
- Discussion: Walter stated that he thought that the only way the process would
  be manageable would be to edit the 6.1 specification directly.  Then we could
  generate a diff when the changes were completed and use the diff to draft a
  single BIRD describing the changes.  He also thought that we would be unlikely
  to run into anything that would require drafting separate additional BIRDs.
  No one disagreed with this approach.  Mike did suggest that we might want to
  keep some additional notes during the discussion, as he was concerned that we
  had enough documentation of any changes in the event that we pursued adopting
  IBIS 6.2 as a formal standard.  Bob suggested that we might simply keep a list
  of the pages on which changes were made, as a supplement to the final diff
  of the changes, to help with drafting the final BIRD.  Walter and Arpad asked
  if anyone objected to this proposed process.  No one did.  Arpad then
  suggested that the ATM meetings were not particularly busy at this time, so we
  could work on these changes in the ATM meetings.  Everyone agreed that we
  would start this way and potentially open up the Friday time slot for this
  work if the ATM meeting became busy with additional topics.  Arpad suggested
  that we should have an editor-in-chief for this process.  Bob said that he
  would like to see if Michael Mirmak were willing to take on this role, as he
  had done it well and consistently in the past.  Mike and Bob said they would
  contact Michael Mirmak.  Michael Mirmak was also believed to be the keeper of
  the original Visio figures in the spec., some of which may need to be edited.
  
Discussion of issue discovered with ibischk 6.1.0
- Bob: We have a problem with ibischk 6.1.0 when checking matrix based
       [Package Models], primarily due to numerical resolution.
  - New off diagonal testing rules may produce many failures in working
    [Package Models].
  - Be careful implementing this version in tools.  Wait for the next version
    of ibischk.  For instance, summation of off diagonal elements might yield
    a magnitude greater than the diagonal element just due to numerical issues.
- Discussion: Walter suggested a tolerancing scheme based on 1e-4 (or some other
  multiple) times the sum of the absolute values of the elements in the row.
  Bob said a similar tolerancing scheme was being introduced.  Walter asked if
  the Capacitance matrix diagonal checking was based on passivity, and said that
  1e-3 was probably a tight enough tolerance in that case.  Mike mentioned that
  in his testing about 50% of the files that failed with zero tolerance passed
  when he implemented a tolerance of 1e-5 * (the sum of absolute values).  But
  he had to go to 1e-3 before all examples passed.  Randy then said that Mike
  had in fact found some examples of bad package models.  Randy wanted to look
  into those bad package models before suggesting a tolerance.  Mike and Bob
  said they were implementing a two tiered scheme with separate thresholds for
  warning and error.  Randy agreed to get back to them with suggestions for the
  two thresholds.

- Arpad: Thank you all for joining.

-------------
Next meeting: 08 December 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
